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Abstract 


The  development  of  a consensus  model  for  building-project  information  requires  a 
precise  description  of  the  meaning  of  the  information  to  be  maintained.  This  report 
presents  an  analysis  of  the  conceptual  structures  that  are  available  to  specify  that  mean- 
ing using  a proposed  "global  model"  as  an  example.  The  model  is  currently  under 
development  by  the  Architecture,  Engineering,  and  Construction  (AEC)  Committee 
of  the  Initial  Graphics  Exchange  Specification  (IGES)  / Product  Data  Exchange 
Specification  (PDES)  Organization. 

The  key  conclusion  of  this  analysis  is  that  a core  semantic  vocabulary  is  needed.  This 
core  vocabulary  derives  from  how  meaning  is  expressed  without  regard  for  specific 
domains  of  information.  Preliminary  elements  of  such  a core  vocabulary  are  defined. 
Further,  a means  by  which  that  core  is  extended  to  add  necessary  domain-specific 
semantics  is  presented.  The  analysis  has  identified  those  aspects  of  developing  a global 
model  for  building-project  information  that  should  proceed  in  the  context  of  a broad 
interdisciplinary  effort  to  represent  information  and  those  that  require  extensive  tech- 
nical input  from  the  building  industry. 
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1.  Introduction 


1.1  Background 

There  has  been  considerable  interest  in  recent  years  in  the  possibility  of  developing  a 
global  conceptual  model  for  building-project  information.  This  interest  has  intensified 
with  the  advent  of  semantic  modeling  techniques  in  both  the  fields  of  database  manage- 
ment and  artificial  intelligence  [1,2].  Application  of  such  techniques  presents  the  pos- 
sibility of  encoding  building-project  information  in  an  accessible  and  meaningful  form 
for  all  participants  in  the  building  process  over  the  entire  life-cycle  of  a building. 

The  Initial  Graphics  Exchange  Specification  (IGES)  / Product  Data  Exchange 
Specification  (PDES)  Organization  is  developing  a "global  model"1  for  building-project 
information  within  its  Architecture,  Engineering,  and  Construction  (AEC)  Committee 
[3].  Other  conceptual  models  are  also  being  developed  in  conjunction  with  the 
IGES/PDES  AEC  Committee,  however,  reference  to  the  AEC  Model  in  this  report 
refers  to  the  "global  model."  This  AEC  Model  is  a first  step  toward  the  long  term  goal 
of  a global  building-project  information  model.  It  is  being  developed  to  represent  a 
finite  time  in  a building’s  life-cycle  as  a means  of  limiting  the  scope  of  the  problems  en- 
countered in  establishing  industry-wide  specifications  for  such  a large  domain  of  infor- 
mation. 


1.2  Terminology 

The  central  focus  of  this  report  is  the  specification  of  meaning  (i.e.,  semantics)  in  the 
development  of  an  information  system  at  the  logical  level.  It  represents  a synthesis  of 
approaches  to  this  topic  from  a number  of  disciplines  including  database  management, 
artificial  intelligence,  and  linguistics  as  well  as  from  the  building  industry.  Terminol- 
ogy both  within  and  between  these  disciplines  is  extremely  varied.  For  example,  what 
has  been  described  as  a conceptual  model  by  the  IGES/PDES  AEC  Committee  is  often 
referred  to  in  the  database  literature  as  a conceptual  schema.  The  term  "data  model" 
in  this  context  identifies  a formal  approach  to  specifying  a conceptual  schema.  This 
report  adopts  the  use  of  the  word  "model"  as  used  by  the  AEC  Committee  and  uses  it 
interchangably  with  the  term  schema.  The  distinction  between  model  (i.e.,  schema) 
and  data  model  is  maintained. 


1 This  model  has  recently  been  renamed  the  "Building  Systems  Model"  (March  1988). 


Throughout  this  report,  terminology  has  been  adopted  that  is  eclectic  among  the  dis- 
ciplines listed  above.  Therefore,  definitions  are  given  as  terms  are  encountered.  The 
terms  have  been  chosen  to  facilitate  the  discussion  of  the  topics  being  presented  rather 
than  to  endorse  any  given  formal  approach  to  conceptual  modeling. 


1.3  Purpose  and  Organization 

This  report  addresses  issues  of  knowledge  representation  and  semantic  modeling  in  the 
context  of  the  preliminary  AEC  Model  for  building-project  information.  Of  particular 
importance  is  the  initiation  of  a discussion  on  the  process  by  which  such  a model  is 
developed  and  the  conceptual  structures  that  are  chosen  to  represent  information 
during  that  process. 

After  the  introductory  remarks  of  this  section,  Section  2 presents  an  overview  of  the 
basic  conceptual  structures  used  in  the  current  AEC  Model.  The  specification  of  ideas 
is  described  as  both  the  identification  of  largely  domain  specific  concepts  and  the  selec- 
tion of  more  generic  relationships  that  serve  to  establish  the  logical  connections  be- 
tween concepts.  The  relationships  of  the  AEC  Model  are  then  discussed  in  terms  of 
categories  based  on  the  grammatical  constructions  used  in  their  specification. 

Several  alternative  representations  for  specifying  ideas  are  presented  in  Section  3. 
They  include  symmetric,  relational,  and  graphic  representations.  Conversion  from  one 
form  to  the  other  is  discussed.  Relationship  types  reflecting  the  categories  identified 
in  Section  2 are  then  defined.  The  use  of  relationship  types  is  suggested  as  a means  by 
which  a systematic  approach  to  the  specification  of  ideas  can  be  established. 

Section  4 returns  to  the  topic  of  identifying  concepts.  Their  development  through 
specification  of  ideas  is  outlined.  The  discussion  then  proceeds  to  the  identification 
and  development  of  constructs  formed  by  a group  of  hierarchically  related  ideas.  The 
section  ends  with  a discussion  of  concepts  that  serve  as  prototypes  for  other  concepts. 
Examples  from  the  current  AEC  Model  are  used  extensively. 

Section  5 presents  a summary  which  reviews  the  conceptual  model  development 
process.  Conclusions  include  recommending  the  use  of  a systematic  approach  to  the 
specification  of  the  conceptual  structures.  In  particular,  the  use  of  relationship  types  in 
defining  relationships  and  the  explicit  identification  of  constructs  and  prototypes  that 
are  central  to  the  overall  organization  of  building  information  are  advocated.  The  final 
sections  present  an  overview  of  the  schema  development  process  and  the  utility  of  a 
core  conceptual  vocabulary  that  serves  as  the  foundation  for  domain  specific  informa- 
tion models  such  as  those  being  developed  for  the  building  industry. 
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2.  Analysis  of  Conceptual  Structures 


2.1  Overview 

The  AEC  Model  has  served  as  a basis  for  prototype  information  system  implementa- 
tions which  have  been  used  as  testbeds  for  investigating  topics  of  knowledge  repre- 
sentation and  schema  development.  Specifically,  a frame-based  information  system 
has  been  implemented  using  a knowledge-base  development  environment  on  a Lisp 
machine  and  a predicate  logic  based  relational  information  system  has  been  imple- 
mented in  Prolog  with  an  emphasis  on  user  interface  characteristics.  The  latter  system 
was  used  to  explore  desirable  characteristics  of  a schema  development  environment 
that  would  be  of  assistance  in  the  specification  of  conceptual  structures.  A discussion 
of  the  preliminary  AEC  Model  follows  based  on  observations  made  during  the  im- 
plementation of  these  testbed  systems. 


2.1.1  Concepts 

"Concepts"  in  the  context  of  this  report  represent  a class  of  uniquely  identifiable  things, 
events,  or  notions.  Examples  include  the  central  concept  of  a building  project  in  the 
case  of  the  AEC  Model  and  the  building  and  site  that  are  parts  of  a building  project. 
Within  the  field  of  conceptual  modeling,  concepts  are  variously  described  as  concepts 
[4,5],  object  classes  [1],  or  entity  types  [6,7].  Each  of  these  terms  is  meant  to  indicate 
that  a concept  does  not  represent  a particular  building  for  example,  but  rather  repre- 
sents a class  of  which  there  can  be  many  instances,  in  this  case  many  buildings.1 

The  preliminary  AEC  Model  contains  over  500  concepts,  many  of  which  are  domain 
specific.  That  is,  most  of  the  concepts  have  been  specified  in  the  early  stages  of  the 
AEC  Model  development  for  the  explicit  purpose  of  communicating  information  about 
buildings.  No  attempt  has  been  made  in  this  report  to  evaluate  the  suitability  of  the 
concepts  chosen  or  their  ultimate  usability  in  a global  information  model.  This  task 
falls  clearly  within  the  scope  of  the  members  of  the  AEC  Committee  and  others  within 
the  AEC  community  who  will  select  concepts  based  on  the  needs  of  the  participant 
groups  they  represent.  Rather,  issues  of  knowledge  representation  that  apply  to  these 
concepts  as  they  have  been  defined  and  which  would  have  essentially  equal  validity  for 
other  concepts  are  discussed  in  the  sections  which  follow. 


1 The  IGES/PDES  Organization  has  adopted  the  terminology  of  "entity"  to  represent  a con- 

cept and  "occurrence"  to  represent  an  instance  of  a concept. 
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2.1.2  Ideas 


"Ideas"  are  composed  of  several  concepts  and  a relationship  that  establishes  a logical 
connection  between  those  concepts.  "Building  has-part  building-element"  is  an  ex- 
ample of  an  idea. 


2.1.3  Relationships 

"Relationships"  represent  the  logical  connections  between  concepts  in  a conceptual 
model.  In  stating  the  idea  that  "building  has-part  building-element,"  one  is  stating  that 
there  exists  a whole-to-part  relationship  between  the  concept  "building"  and  the  con- 
cept "building-element".  Frequently  in  defining  ideas,  conceptual  models  make  use  of 
alternative  ways  of  stating  the  idea  when  taking  the  perspective  of  one  or  the  other  con- 
cept. Therefore,  "building  has-part  building-element"  and  "building-element  part-of 
building"  can  be  seen  to  be  aspects  of  the  same  idea.  These  representations  can  be  con- 
sidered to  be  an  obverse  and  inverse  representation  of  the  idea.  What  is  emphasized 
in  such  representations  is  the  role  played  by  each  of  the  concepts.  The  idea  can  be  con- 
sidered from  the  perspective  of  the  building  (the  whole)  or  the  building-element  (the 
part)  each  of  which  leads  to  a slightly  different  statement  of  the  relationship  ("has-part" 
and  "part-of1  respectively). 


2.1.3  Relations  and  Roles 

A relationship  can  be  specified  most  clearly  in  terms  of  a relation  and  its  associated 
roles.  A "relation"  identifies  the  nature  of  the  logical  connection.  A "role"  is  a link  that 
can  be  used  between  a relation  with  which  it  is  associated  and  a concept  in  forming  an 
idea.  A role  identifies  the  function  of  the  concept  in  the  idea.  (See  also  [8].) 

The  "has-part/part-of 1 relationship  pair  combines  the  "part"  relation  with  other  words 
that  indicate  the  roles  played  by  each  concept  in  an  idea.  In  the  obverse  representation 
of  our  example,  the  verb  "has"  in  combination  with  part  identifies  the  role  of  the  whole 
as  being  primary  ("building  has-part  building-element").  In  the  inverse  representation, 
the  preposition  "of  identifies  the  role  of  the  part  as  primary  ("building-element  part- 
of  building").  Relationship  pairs  like  "has-part/part-of  then  are  one  means  of  convey- 
ing the  semantics  of  both  a relation  and  associated  roles  of  the  concepts  in  an  idea. 

Often,  however,  the  representation  of  the  relationship  from  the  perspective  of  one  con- 
cept is  quite  obvious,  but  from  the  perspective  of  the  other  concept  seems  forced  or 
unclear.  It  is  straight  forward  to  say  "lighting-fixture  in  ceiling"  but  much  less  so  to  say 
"ceiling  around  lighting-fixture."  Lack  of  clarity  often  results  in  ideas  being  defined  in- 
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completely.  There  are  alternative  ways  of  representing  relationships  explicitly  in  terms 
of  relations  and  associated  roles.  These  will  be  discussed  in  subsequent  sections. 

The  AEC  Model  contains  over  twenty  distinctly  different  relations.  These  relations 
tend  to  be  more  generic  (i.e.,  less  domain  specific)  than  the  concepts  of  the  model.  The 
relation  "part”  is  an  example  of  a relation  that  is  clearly  not  limited  to  the  building  in- 
dustry. In  fact,  the  possibility  that  there  exists  a finite  set  of  generic  relations  will  be 
considered  in  later  sections.  Developing  a particular  model  such  as  the  AEC  Model 
could  therefore  involve  a process  of  selection  from  among  generic  relations,  defining 
new  domain  specific  relations  only  when  necessary. 


2.2  Relationship  Types 

The  preliminary  AEC  Model  uses  an  idea  representation  that  employs  the  use  of 
relationship  pairs  such  as  "has-part/part-of'  in  defining  ideas.  Four  general  types  of 
relationships  have  been  identified.  The  relationship  types  derive  from  certain  gram- 
matical constructions  that  can  be  used  in  the  specification  of  ideas  [8].  They  include 
active,  dative,  locative,  and  partitive  relationships.  Obverse  and  inverse  repre- 
sentations of  example  ideas  using  these  relationship  types  are  listed  in  Table  1. 


Table  1.  Example  Ideas  using  Four  Relationship  Types. 

Relationship  Type 

Obverse  Representation 

Inverse  Representation 

Active 

x controls  y 

y controlh d-by  x 

Dative 

x conducts-z-to  y 

y receives-z- from  x 

Locative 

xony 

y under  x 

Partitive 

x has  -party 

y part-oix 

An  active  relationship  uses  a verb  in  the  active  and  passive  voice  in  its  obverse  and  in- 
verse representations  respectively.  The  idea  "hvac-system  controls  air-quality"  is  an  ex- 
ample of  an  obverse  representation.  An  active  relationship  is  most  easily  identified  by 
the  inverse  representation  which  uses  the  preposition  "by"  as  in  "air-quality  controlled- 
by  hvac-system."  A listing  of  the  active  relations  contained  in  the  AEC  Model  is 
presented  in  Table  2.  Active  relations  in  this  table  are  named  by  verbs  only  without 
reference  to  the  use  of  the  preposition  "by"  used  to  distinguish  roles. 
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Table  2.  Relations  of  the  AEC  Descriptive  Model. 

Active 

Dative 

Locative 

Partitive 

accesses  (5)* 
connects  (8) 
contains  (5) 
controls  (1) 
defines  (3) 
divides  (5) 
generates  (2) 
protects  (1) 
serves  (6) 
supports  (2) 
triggers  (1) 

applies 
-finish  (1) 
conducts 
-waste  (7) 
-water  (9) 
exhausts 
-air  (3) 
leads 

-[person]  (1) 

in  (2) 
on  (2) 

function  (20) 
part  (20) 

StS6t  (485) 
subtype 

* Numbers  in  parentheses  indicate 
frequency  of  occurrance. 

A dative  relationship  is  more  complex  than  an  active  relationship.  Dative  relation- 
ships include  a verb  with  the  prepositions  "to"  and  "from"  in  their  obverse  and  inverse 
representations.  An  example  of  a dative  relationship  from  the  AEC  Model  is  "gutter 
conducts-water-to  down-spout."  The  AEC  Model  does  not  contain  an  inverse  for  this 
relationship  though  something  like  "down-spout  receives-water-from  gutter"  might  be 
chosen.  Three  concepts  are  identifiable  (e.g.,  gutter,  water,  and  down-spout)  in  an  idea 
containing  such  a dative  relationship.  The  idea  typically  involves  the  transfer  of  a thing 
from  one  object  or  place  to  another.  Ideas  involving  transferrence  (often  discussed  in 
the  context  of  "directed  networks")  deserve  special  attention.  The  AEC  Model  chose 
to  use  a single  binary  representation  for  an  idea  involving  a dative  relationship  in  which 
the  thing  being  transferred  is  included  as  part  of  the  relationship.  Alternatives  to  this 
approach  will  be  discussed  in  subsequent  sections.  (See  3.2.2  and  3.3.) 

Table  2 lists  the  dative  relations  of  the  AEC  Model.  There  are  five  relationship  pairs 
which  identify  dative  relations.  They  include  "applies-finish-to,"  "conducts-waste-to," 
"conducts-water-to,"  "exhausts-air-to,"  and  "leads-[person]-to"  (and  their  inverses). 
The  prepositions  "to"  and  "from"  are  not  included  in  Table  2 since  these  prepositions 
serve  to  identify  roles  rather  than  the  relation  itself.  Further,  the  verb  and  the  object 
which  constitutes  the  third  concept  in  a dative  relationship  are  separated.  An  ad- 
vantage of  listing  dative  relations  in  this  way  is  that  it  identifies  each  of  the  elements 
explicitly.  Within  the  AEC  Model  the  relationship  involving  the  application  of  a finish 
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does  not  involve  three  concepts  as  does  the  generalized  dative  relationship.  Rather  it 
is  expressed  as  "finish  applied-to  enclosure-component."  A dative  relationship  using 
the  generalized  form  would  suggest  an  implied  third  concept,  perhaps  "[subcontractor] 
applies-finish-to  enclosure-component."  Similarly,  there  is  an  implied  concept  in  the 
relationship  "emergency-egress-route  leads-[person]-to  exit." 

A locative  relationship  is  identified  by  a preposition  as  in  "lighting-fixture  in  ceiling."1 
The  inverse  representation  of  locative  relationships  are  not  always  clear.  Though  tech- 
nically speaking  one  might  use  "ceiling  around  lighting-fixture,"  this  inverse  relation- 
ship seems  quite  unnatural  which  may  account  for  the  fact  that  the  AEC  Model  does 
not  include  an  inverse  for  this  relationship.  Alternative  means  of  specifying  the  roles 
played  by  concepts  in  a relationship  can  be  employed  to  allay  this  difficulty.  This  is  of 
particular  interest  since  relations  involved  in  locative  relationships  appear  to  be  generic 
rather  than  domain  specific  lending  them  to  standardization. 

A partitive  relationship  is  identified  by  the  use  of  a noun  in  combination  with  the  verb 
"has"  in  the  obverse  and  by  the  preposition  "of'  in  the  inverse.  "Building  has-part  build- 
ing-element" and  "building-element  part-of  building"  are  examples  of  a partitive 
relationship.2  Moreover,  the  relationship  pair  "has-part/part-of ' identifies  a whole-to- 
part  relationship  that  is  a member  of  a subcategory  of  partitive  relationships  involving 
generalization  [9].  Part-generalization  can  have  implicit  characteristics  in  knowledge- 
based  information  systems.  For  example,  instances  of  a concept  representing  a whole 
can  have  instances  of  parts  assigned  automatically.  This  is  a special  kind  of  inheritance 
that  can  be  very  useful.  Therefore,  the  appropriate  use  of  part-generalization  should 
be  considered  in  the  development  of  a conceptual  schema. 

Generalization  can  also  be  indicated  by  two  other  relationship  pairs,  "has-subset/sub- 
set-of ' and  "has-subtype/subtype-of."3  The  former  pair  identifies  a set-generalization. 
Set-generalization  does  not  involve  inheritance  of  ideas.  This  derives  from  the  fact  that 
there  are  not  inherent  similarities  among  members  of  a set  other  than  that  they  are 
each  members  of  the  same  set.  An  example  from  the  AEC  Model  is  the  concept  of 
topography  ("topography  has-subset  elevation,"  "topography  has-subset  orientation," 
and  "topography  has-subset  slope").  In  these  ideas  the  concept  "topography"  is  iden- 
tified as  comprising  subsets  of  information  on  elevation,  orientation,  and  slope.  These 
subsets  taken  together  constitute  what  is  meant  by  topography.  They  do  not  inherit 
ideas  from  the  concept  topography  which  they  serve  to  define. 


1 Locative  relationships  have  an  implied  verb  "is"  as  in  "lighting  fixture  is-in  ceiling." 

2 The  inverse  representation  of  a partitive  relationship  has  an  implied  "is"  as  in  "building-ele- 
ment is-part-of  building." 

3 In  many  knowledge-based  systems,  the  "has-subtype/subtype-of'  relationship  pair  is  dis- 
cussed as  the  "is-a"  relationship,  where  "subtype"  is  implied  but  not  stated  explicitly. 


7 


Type-generalization  uses  the  third  relationship  pair  used  in  generalizations  ("has-sub- 
type/subtype-of').  "Engineering-system  has-subtype  mechanical-system"  and  the  in- 
verse "mechanical-system  subtype-of  engineering-system"  is  an  example.  The  use  of 
these  relationship  pairs  identifies  a type-generalization  which  can  be  extended  from 
one  concept  to  another  forming  a type-generalization  hierarchy.  An  important  aspect 
of  such  use  of  type-generalization  is  the  fact  that  many  knowledge-based  information 
systems  use  type-generalization  for  inheritance.  That  is,  the  concept  mechanical-sys- 
tem would  inherit  ideas  from  the  concept  engineering-system. 

The  distinction  between  generalizations  involving  parts,  subsets,  and  subtypes  can  be 
of  major  importance  in  developing  conceptual  schemas.  This  selection  is  often  com- 
plicated, however,  by  the  fact  that  the  distinctions  made  here  between  part-,  set-,  and 
type-generalization  are  not  universally  observed  by  various  modeling  techniques.  In 
the  case  of  the  AEC  Model,  the  use  of  a particular  modeling  technique  has  resulted  in 
some  confusion  among  these  choices.1 

In  addition  to  generalization,  a second  subcategory  of  partitive  relationships  involves 
what  can  be  grouped  together  as  characterization.  This  category  includes  all  partitive 
relations  that  do  not  involve  generalization.  An  example  would  be  the  relationship  pair 
"has-function/function-of."  As  with  the  concepts  themselves,  relations  used  to  charac- 
terize concepts  can  be  either  generic  or  domain  specific  in  contrast  to  those  involving 
generalization  which  include  the  three  generic  relations:  part,  subset,  and  subtype. 

Table  2 lists  the  frequency  of  occurrence  of  the  relations  in  the  AEC  Model.  At  the 
current  phase  of  development  most  relationships  involve  generalization  (i.e.,  the  rela- 
tions part,  subset,  and  subtype).  This  reflects  the  development  of  the  top  level  of  or- 
ganization for  the  conceptual  schema  and  the  descriptive  function  of  the  AEC  Model 

It  has  also  been  observed  that  locative  and  partitive  relations  involving  generalization 
tend  to  be  generic  (i.e.,  less  domain  specific).  In  contrast,  the  active  and  dative  rela- 
tions appear  to  be  more  specific  to  the  building  industry.  Partitive  relations  involving 
characterization  can  be  either  generic  or  domain  specific.  Whether  these  tendencies 
will  continue  to  be  true  as  the  AEC  Model  is  developed  and  whether  conceptual 
schemas  in  other  domains  display  these  same  tendencies  requires  further  attention.  It 
represents  an  area  of  schema  development  and  specification  where  various  domains 
can  contribute  to  one  another’s  precision  as  well  as  holding  potential  for  long  term  com- 
patibility among  domain  specific  systems  through  the  development  of  conventions. 


1 The  data  model  used  by  the  IGES/PDES  AEC  committee  in  developing  its  "global  model"  is  referred 

to  as  information  analysis  [10].  The  notation  used  by  information  analysis  provides  a unique  and 
simple  representation  for  type-generalization.  It  does  not,  however,  provide  similar  capabilities  for 
part-  and  set-  generalization. 
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3.  Specifying  Ideas 


3.1  Alternative  Representations 

The  field  of  conceptual  modeling  has  in  recent  years  had  many  alternative  methods 
suggested  for  representing  semantics  in  conceptual  schemas  [1].  Often  these  repre- 
sentations are  part  of  a comprehensive  approach  to  conceptual  modeling  called  a data 
model  (though  it  might  be  more  useful  to  think  of  these  data  models  as  conceptual 
tools).  The  alternative  representations  have  as  their  goal  the  expression  of  the  under- 
lying meaning  of  a conceptual  schema.  Three  general  ways  of  representing  ideas  are 
useful  in  discussing  the  AEC  Model.  They  include  symmetric,  relational,  and  graphic 
representations. 


3.1.1  Symmetric  Representation 

The  most  intuitive  of  the  three  representations  is  referred  to  here  as  a symmetric  rep- 
resentation. The  ideas  of  the  AEC  Model  and  the  description  of  example  ideas  in  Sec- 
tion 2 use  a symmetric  representation.  Symmetric  representations  account  for  the  fact 
that  the  concepts  are  often  of  central  importance  in  understanding  a conceptual 
schema.  With  this  in  mind,  one  defines  relationship  pairs  that  suggest  the  roles  played 
by  each  of  the  concepts  in  an  idea  such  that  the  idea  can  be  viewed  from  the  perspec- 
tive of  any  given  concept.  In  many  information  systems,  the  relationship  pairs  are 
defined  as  individual  but  associated  "relations."  They  are  associated  in  the  sense  that 
they  are  the  inverse  of  one  another.  Therefore,  when  the  idea  "building  has-part  build- 
ing-element" is  established  in  such  a conceptual  schema,  the  inverse  "building-element 
part-of  building"  should  also  be  established. 

Two  types  of  difficulties  are  often  present  in  developing  a conceptual  schema  using  a 
symmetric  representation.  The  first  is  the  uncertainty  in  assigning  inverse  roles.  If  we 
wish  to  establish  "lighting-fixture  in  ceiling,"  is  the  inverse  "ceiling  around  lighting-fix- 
ture?" The  second  difficulty  involves  semantic  errors  that  stem  from  mixing  relations. 
The  classic  example  not  taken  from  the  building  industry  is  the  use  of  "x  grandfather- 
of  y"  and  "y  grandson-of  x."  In  addition  to  not  taking  into  account  granddaughters,  the 
establishment  of  these  relationships  as  being  inverses  of  one  another  misses  the  fact 
that  there  are  two  relations  employed  with  the  following  relationship  pairs:  "has- 
grandfather/grandfather-of'  and  "has-grandson/grandson-of."  Developing  a concep- 
tual schema  using  a symmetric  representation  of  relationships  always  has  the  potential 
for  difficulties  of  the  above  kinds. 
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3.1.2  Relational  Representation 


An  alternative  to  the  symmetric  representation  of  ideas  is  the  use  of  a relational  (or 
predicate  logic)  representation.  The  meaning  contained  within  the  relationship  pairs 
of  the  symmetric  representation  is  established  through  the  use  of  compositional  seman- 
tics (i.e.,  the  position  in  an  abstracted  idea).  The  first  element  of  the  idea  is  the  rela- 
tion that  describes  the  logical  connection  between  concepts.  The  position  of  each  sub- 
sequent concept  within  the  idea  indicates  its  role.  In  the  above  example,  the  relation 
"part"  would  be  used  to  define  an  abstract  idea  involving  appropriate  roles  such  as  "part 
(Whole,  Part)."1  Then  for  a given  instance  of  the  abstract  idea,  the  role  played  by  each 
concept  is  established  by  its  position  as  in  "part  (building,  building-element)." 

A relational  representation  alleviates  uncertainty  that  derives  from  the  need  to  define 
relationship  pairs  required  by  a symmetric  representation.  However,  since  there  is  no 
standardization  with  regard  to  which  position  within  an  abstract  idea  will  identify  a 
given  role,  assignment  is  left  to  the  developer  and  can  vary  from  one  system  to  the  next. 
Even  within  a given  system  it  is  uncertain  intuitively  which  role  is  associated  with  which 
position.  Som§  degree  of  consensus  on  this  topic  would  be  most  beneficial. 


3.1.3  Graphic  Representation 

Another  representation  useful  in  specifying  ideas  employs  a graphical  notation  such  as 
that  developed  to  represent  the  meaning  contained  in  natural  language  called  the  con- 
ceptual graph  [4].  A conceptual  graph  uses  brackets  to  enclose  concepts  and  paren- 
theses to  enclose  relations  between  concepts.  Directed  arrows  connote  implicit  roles 
of  the  concepts  in  the  idea.  The  conceptual  graph  for  a whole-to-part  relationship  be- 
tween "building"  and  "building-element"  is  expressed  as: 

[ building  ] — (part)  ->  [ building-element  ] 

Using  a relation  in  a conceptual  graph  suggests  that  it  has  previously  been  declared  to 
be  a relation  associated  with  explicit  roles.  A formal  derivation  of  a relation  using  con- 
ceptual graphs  is  beyond  the  scope  of  this  report  [4].  However,  the  above  idea  involv- 
ing the  part  relation  can  be  stated  simply  but  explicitly  using  the  following  notation: 


1 The  language  Prolog  [11]  uses  this  syntax  which  can  be  used  to  specify  ideas  in  an  information  sys- 
tem. Alternatively,  a relational  representation  can  be  expressed  as  a simple  list  of  elements  as  in 
"[part,  Whole,  Part]." 
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( part ) - 

{Whole}  - [ building  ] 

{Part}  - [ building-element  ] 

This  can  be  generalized  to  the  following  abstract  representation  of  an  idea: 

( Relation  ) - 

{Role}  - [ Concept  ] 

{Role}  - [ Concept  ] 


3.2  Defining  and  Using  Relationship  Types 

In  reviewing  the  AEC  Model,  it  was  observed  that  many  of  the  ideas  were  similar  in 
terms  of  the  relationships  used.  Four  relationship  types  were  sufficient  for  grouping 
all  relationships.  The  relationship  types  used  for  this  purpose  were  Active,  Dative, 
Locative,  and  Partitive.  These  names  were  chosen  to  reflect  natural  language  construc- 
tions that  can  be  used  in  expressing  relationship  pairs  in  a symmetric  representation  of 
ideas.  The  notation  introduced  in  the  previous  section  can  be  used  to  define  the  four 
relationship  types  with  explicit  roles  which  hold  for  all  relationships  that  are  of  that 
type. 


3.2.1  Active  Relationships 

Active  relationships  are  defined  using  an  active  relation  (ActRel)  and  roles  identifying 
an  actor  (Actor)  and  an  acted  upon  object  (ActObj)  as  follows  (the  relationship  ap- 
pears in  bold  face  in  this  and  subsequent  definitions  of  relationship  types): 

( ActRel ) - 

{Actor}  - [ Concept  ] 

{ActObj}  - [ Concept  ] 

Specifying  an  idea  that  uses  an  active  relationship  therefore  requires  identifying  the 
ActRel  and  the  Concepts  in  accordance  with  this  type  definition. 

( controls ) - 

{Actor}  - [ hvac-system  ] 

{ActObj}  - [ air-quality  ] 
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Active  relationships  therefore  are  seen  as  comprising  an  active  relation  and  two  con- 
cepts that  fulfill  the  roles  of  Actor  and  ActObj.  Since  the  specification  of  such  a 
relationship  serves  to  declare  the  existence  of  a given  active  relation,  it  can  thereafter 
be  represented  in  an  implicit  representation  as: 

[ hvac-system  ] (controls)  ->  [ air-quality  ] 

This  is  the  format  that  was  first  introduced  for  an  implicit  graphic  representation  of  an 
idea,  but  has  been  derived  in  a way  that  removes  ambiguity  as  to  the  roles  played  by 
each  concept  in  the  idea.  Establishing  the  roles  which  are  a part  of  the  graph  makes 
the  meaning  explicit.  Table  3 lists  the  ideas  which  involve  active  relationships  in  the 
AEC  Model  in  terms  of  an  ActRel,  an  Actor,  and  an  ActObj. 

Once  defined  in  this  fashion,  specifying  a relational  representation  for  ideas  using  ac- 
tive relationships  can  be  stated  in  terms  of  the  following  abstraction  and  example: 

ActRel  (Actor,  ActObj) 
controls  (hvac-system,  air-quality) 

If  there  is  consensus  on  the  order  in  which  the  roles  are  listed  for  the  abstracted  idea, 
a source  of  confusion  is  avoided  in  specifying  all  further  ideas  that  use  this  relationship 
type. 


3.2.2  Dative  Relationships 

Dative  relationships  have  been  defined  using  a dative  relation  (DatRel)  and  roles  iden- 
tifying a dative  object  (DatObj),  a source  (Source),  and  a target  object  (Target)  as  fol- 
lows: 


( DatRel ) - 

{DatObj}  - [ Concept  ] 

{Source}  - [ Concept  ] 

{Target}  - [ Concept] 

Specifying  an  idea  that  uses  a dative  relationship  therefore  requires  identifying  the  Dat- 
Rel and  the  Concepts  playing  the  roles  of  DatObj,  Source,  and  Target. 

(conducts)  - 

{DatObj}  -[water] 

{Source}  -[gutter] 

{Target}  - [ down-spout  ] 
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Table  3.  Ideas  Using  Active  Relationships  of  the  AEC  Model. 

ActRel 

Actor 

ActObj 

accesses 

artificial-light-system 

engineering-system 

natural-light-sytem 

electrical-system 

utility-system 

opening 

connects 

air-distribution-network 

electric-circuit-network 

footing-drain 

stack 

water-distribution-network 

water-distribution-network 

water-distribution-network 

water-distribution-network 

hvac-distribution-device 

electrical-component 

cleanout 

vent 

water-fixture 

hvac-distribution-device 

standpipe-component 

sprinkler-component 

contains 

circulation-system 

emergency-egress-route 

enclosure-component 

occupied-room 

space 

emergency-egress-route 

room 

opening 

furniture 

equipment 

controls 

hvac-system 

air-quality 

defines 

enclosure-system 

external-envelope 

internal-subdivision 

room 

exterior 

interior 

divides 

electric-zone 

hvac-zone 

lighting-zone 

sprinkler-zone 

standpipe-zone 

electrical-system 

hvac-system 

lighting-system 

sprinkler-system 

standpipe-system 

(continued) 
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Table  3.  (continued) 

ActRel 

Actor 

ActObj 

generates 

luminaire 

luminaire 

heat 

noise 

protects 

over-current-device 

electric-circuit-network 

serves 

street-main 

meter 

service-equipment 

feeder 

branch-circuit 

junction-box 

meter 

service-equipment 

feeder 

branch-circuit 

junction-box 

electric-equipment-network 

supports 

structural-system 

raceway 

building-system-component 

electric-circuit-network 

triggers 

control 

instrument 

An  idea  involving  a dative  relationship  therefore  is  seen  as  comprising  a dative  rela- 
tion and  three  concepts  that  fulfill  the  roles  of  DatObj,  Source,  and  Target.  Table  4 
lists  the  ideas  that  involve  dative  relationships  in  the  AEC  Model  in  terms  of  these  com- 
ponents. 

An  implicit  representation  of  a dative  relationship  is  problematic  in  that  it  is  not  a bi- 
nary relationship.  Dative  relationships  can  be  viewed  as  a binary  relationship  in  which 
the  DatRel  and  DatObj  are  combined  to  form  a unique  relation.  The  AEC  Model  ex- 
presses dative  relationships  in  this  fashion.  The  implicit  representation  of  an  idea  in- 
volving a dative  relationship  resulting  from  the  combination  of  the  DatRel  and  the  Dat- 
Obj is  as  follows: 


[ gutter  ] (conducts-water)  [ down-spout  ] 


Table  4.  Ideas  Using  Dative  Relationships  of  the  AEC  Model. 

DatRel 

Source 

Target 

-DatObj 

applies 

-finish 

[subcontractor] 

enclosure-component 

conducts 

-waste 

branch-soil-pipe 

stack 

building-drain 

bulding-trap 

building-sewer 

main-sewer 

building-trap 

building-sewer 

fixture-trap 

branch-soil-pipe 

fresh-air-fixture 

fixture-trap 

stack 

building-drain 

-water 

down-spout 

discharge-component 

footing-drain 

sand-interceptor 

gutter 

down-spout 

gutter 

roof-drain 

large-paved-area 

discharge-component 

roof 

gutter 

roof-drain 

discharge-component 

sand-interceptor 

discharge-component 

steep-slope 

discharge-component 

exhausts 

-air 

branch-vent 

vent 

fresh-water-fixture 

branch-vent 

vent 

vent-stack-terminal 

leads 

[-person] 

emergency-egress-route 

exit 
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A relational  representation  for  such  an  idea  involving  a binary  dative  relationship  can 
be  stated  in  terms  of  the  following  abstraction  and  example: 

DatRel-DatObj  (Source,  Target) 

conducts-water  (gutter,  down-spout) 

The  alternative  to  the  above  combination  of  the  DatRel  and  the  DatObj  is  a repre- 
sentation which  accommodates  a tertiary  relationship. 

DatRel  (DatObj,  Source,  Target) 
conducts  (water,  gutter,  down-spout) 

The  latter  representation  of  an  idea  involving  a tertiary  dative  relationship  is  preferred 
to  the  form  which  combines  the  dative  relation  and  object.  (See  Section  3.3  for  a fur- 
ther discussion  of  this  topic.) 


3.2.3  Locative  Relationships 

Locative  relationships  have  been  defined  using  a locative  relation  (LocRel)  and  roles 
which  identify  a located  object  (LocObj)  and  a location  (Location)  as  follows: 

( LocRel ) - 

{LocObj}  - [ Concept  ] 

{Location}-  [ Concept  ] 

Specifying  an  idea  that  uses  a locative  relationship  requires  identifying  appropriate 
components  in  accordance  with  the  type  definition. 

(in)  - 

{LocObj}  - [ lighting-fixture  ] 

{Location}-  [ ceiling  ] 

Ideas  which  involve  locative  relationships  are  seen  as  comprising  a locative  relation  and 
two  concepts  that  fulfill  the  roles  of  LocObj  and  Location.  Table  5 lists  the  ideas  in- 
volving locative  relationships  of  the  AEC  Model  in  terms  of  a LocRel,  a LocObj,  and 
a Location. 
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Table  5. 

Locative  Relationships  of  the  AEC  Model. 

LocRel 

LocObj 

Location 

in 

lighting-fixture 

ceiling 

outside-siamese-connector 

exterior-wall 

sprinkler-head 

ceiling 

on 

building 

site 

roof-manifold 

roof 

An  implicit  representation  of  the  above  example  idea  using  a locative  relationship  is: 

[ lighting-fixture  ] -»  (in)  -*  [ ceiling  ] 

A relational  representation  for  ideas  using  a locative  relationship  can  be  stated  in  terms 
of  the  following  abstraction  and  example: 

LocRel  (LocObj,  Location) 
in  (lighting-fixture,  ceiling) 

Though  most  locative  relationships  are  binary  there  exists  the  possibility  of  tertiary  or 
higher  order  locative  relationships.  The  relation  "between"  requires  the  ability  to  deal 
with  higher  order  relationships.  A locative  relationship  involving  the  relation  between 
would  necessarily  have  at  least  two  (and  possibly  more)  concepts  with  the  Location 
role.  Since  the  roles  of  each  of  these  concepts  is  the  same,  additional  locations  can  be 
accommodated  by  repeating  that  role. 


3.2.4  Partitive  Relationships 

Partitive  relationships  have  been  defined  using  a partitive  relation  (ParRel)  and  roles 
indicating  a primary  object  (PrimObj)  and  an  auxiliary  object  (AuxObj)  as  follows: 

( ParRel )- 

{PrimObj}  - [ Concept  ] 

{AuxObj } - [ Concept  ] 
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The  roles  PrimObj  and  AuxObj  have  been  chosen  so  they  can  be  applied  to  both  sub- 
categories of  partitive  relationships  (i.e.,  both  generalization  and  characterization). 
Specifying  an  idea  using  a partitive  relationship  requires  identifying  each  of  the  com- 
ponents: 


(subtype)  - 

{PrimObj}  - [ engineering-system  ] 

{AuxObj}  - [ mechanical-system  ] 

An  idea  involving  a partitive  relationship  therefore  has  a partitive  relation  and  two  con- 
cepts that  fulfill  the  roles  of  PrimObj  and  AuxObj.  An  implicit  representation  of  the 
above  idea  is: 

[ engineering-system  ] (subtype)  -*  [ mechanical-system  ] 

A relational  representation  for  an  idea  using  a partitive  relationship  can  be  stated  in 
terms  of  the  following  abstraction  and  example: 

ParRel  (PrimObj,  AuxObj) 

subtype  (engineering-system,  mechanical-system) 

Most  ideas  in  the  AEC  Model  involve  partitive  relationships.  A table  of  the  ideas  that 
employ  partitive  relationships  in  terms  of  ParRel,  PrimObj,  and  AuxObj  is  not  included 
in  this  report.  Most  of  the  partitive  relations  of  the  AEC  Model  (see  Table  2)  involve 
generalization  but  do  not  consider  the  distinctions  suggested  previously.  In  those  cases 
where  inheritance  is  judged  to  be  relevant,  the  distinction  between  part-  and  type- 
generalization  should  be  considered.  In  those  that  do  not  involve  inheritance,  set- 
generalization  is  appropriate.  This  topic  will  be  discussed  in  terms  of  specific  examples 
used  to  organize  information  within  the  conceptual  schema  in  Section  4.2. 


3.3  Complex  Ideas 

Ideas  involving  dative  relationships  contain  a dative  relation  and  three  concepts  (an 
arity  of  three  when  considered  from  the  perspective  of  a relational  representation). 
Such  ideas  while  easily  represented  in  a relational  form  are  not  represented  accurate- 
ly by  a single  symmetric  binary  idea.  Therefore,  an  alternative  representation  is 
desirable.  A complex  idea  requires  a representation  which  employs  more  than  one  bi- 
nary idea  to  convey  the  required  semantics. 
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3.3.1  Representing  Complex  Ideas 

An  idea  involving  a dative  relationship  contains  a dative  relation  (DatRel)  and  three 
concepts  having  the  roles  of  a dative  object  (DatObj),  a source  (Source),  and  a target 
(Target)  as  in  the  following  example  (not  from  the  AEC  Model): 

(ships)  - 

{DatObj}  - [ material  ] 

{Source}  - [ supplier  ] 

{Target}  - [ contractor  ] 

Such  a tertiary  idea  can  be  represented  in  a binary  format  using  one  binary  idea  involv- 
ing an  active  relationship  and  two  binary  ideas  involving  partitive  relationships.  An  ad- 
ditional concept  is  used  that  identifies  an  implied  process  of  transfer  (e.g.,  "supplier- 
to-contractor-material-transfer"). 

(ships)  - 

{Actor}  -[  supplier-to-contractor-material-transfer  ] 

{ActObj}  -[material] 

(origin)  - 

{PrimObj}-[  supplier-to-contractor-material-transfer  ] 

{AuxObj}  -[  supplier  ] 

(destination)  - 

{PrimObj}-[  supplier-to-contractor-material-transfer  ] 

{AuxObj}  -[  contractor  ] 

The  corresponding  implicit  representations  are  as  follows: 

[ supplier-to-contractor-material-transfer  ] (ships)  -»>  [ material  ] 

[ supplier-to-contractor-material-transfer  ] (origin)  ->  [ supplier  ] 

[ supplier-to-contractor-material-transfer  ] (destination)  [ contractor  ] 

The  relational  representations  for  these  ideas  are: 

ships  (supplier-to-contractor-material-transfer,  material) 
origin  (supplier-to-contractor-material-transfer,  supplier) 
destination  (supplier-to-contractor-material-transfer,  contractor) 

The  relationship  pairs  of  a symmetric  representation  are  "ships/shipped-by,"  "has- 
origin/origin-of,"  and  "has-destination/destination-of 1 respectively. 
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3.3.2  The  Utility  of  Complex  Ideas 


An  underlying  concept  of  transfer  appears  central  to  the  representation  of  complex 
ideas  involving  dative  relationships  as  currently  defined.  Semantic  information  is  ap- 
propriately maintained  within  a binary  format  by  establishing  a complex  idea  centered 
around  this  additional  concept. 

While  using  an  idea  involving  an  active  relationship  in  representing  a complex  idea  falls 
within  the  scope  of  previous  discussions,  combining  such  an  idea  with  paired  ideas  in- 
volving partitive  relationships  to  express  direction  adds  another  aspect  to  the  repre- 
sentation of  ideas.  Such  pairing  of  ideas  has  been  identified  in  the  field  of  natural  lan- 
guage processing  by  Schank  [8].  In  addition  to  the  expression  of  direction  (from  source 
to  target)  is  that  of  state  change  (from  initial  to  final  states).  Both  direction  and  state 
change  fit  well  within  the  context  of  the  transfer  process  as  being  central  to  complex 
ideas  involving  dative  relationships. 

Certainly  the  idea  of  directed  transfer  is  useful  to  the  building  industry  especially  in  the 
context  of  "directed  networks."  Many  building  systems  can  be  viewed  as  a collection  of 
connected  and  ordered  components  that  transfer  a given  thing  for  the  purpose  of  satis- 
fying explicit  functional  requirements.  The  potential  of  the  complex  idea  mechanism 
representing  not  only  directed  transfer  but  also  state  change  will  continue  to  be  an  ac- 
tive topic  of  research. 
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4.  From  Initial  Concepts  to  Constructs 


4.1  Developing  Concepts 

Initial  concepts  are  chosen  by  individuals  who  understand  the  needs  of  the  given 
domain  for  which  a conceptual  schema  is  being  developed.  Therefore,  it  is  the  par- 
ticipants involved  in  the  design,  construction,  and  maintenance  of  a building  throughout 
its  entire  life  cycle  that  ultimately  determine  the  concepts  that  must  be  represented  in 
a global  model.  The  preliminary  AEC  Model  used  as  a basis  of  discussion  in  this  report 
is  a first  step  toward  identifying  a comprehensive  set  of  concepts  for  the  building  in- 
dustry. 

Once  a concept  such  as  building  is  identified,  it  can  be  represented  using  the  concep- 
tual graph  form  [building].  This  form  represents  the  initial  concept.  The  next  step  is 
to  begin  to  develop  the  concept  by  specifying  ideas  in  which  the  concept  is  logically 
connected  to  other  concepts,  such  as: 

[ building  ] -*  (part)  -*  [ building-element  ] 

An  idea  can  also  be  expressed  in  the  following  form: 

(part) 

[building] 

[building-element] 

This  representation  can  be  further  abbreviated  by  assuming  that  the  first  concept  points 
toward  the  relation  and  the  second  points  away  from  it  as  follows: 

(part) 

[building] 

[building-element] 

The  form  can  then  be  used  in  a shorthand  version  which  includes  similar  ideas  involv- 
ing the  same  relation  and  initial  concept  by  adding  the  concepts  to  which  the  initial  con- 
cept is  related  from  those  other  ideas. 

(part) 

[ building  ] 

[ building-element  ] 

[ building-system  ] 
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What  is  understood  to  constitute  the  concept  of  a building  at  later  stages  of  concept 
development  includes  all  those  ideas  in  which  the  concept  is  directly  involved  (i.e.,  an 
aggregation  of  ideas  [9]).  The  developed  concept  of  a building  in  the  AEC  Model  can 
be  represented  as: 

(part) 

[building-project] 

[building], 

(part) 

[building] 

[building-element] 

[building-system], 

(on) 

[building] 

[site], 

(function) 

[building] 

[building-function] . 


4.2  Identifying  Constructs 

Constructs  are  hierarchical  conceptual  structures  formed  by  a synthesis  of  ideas  that 
involve  generalization.  In  the  case  of  part-generalization,  for  example,  a given  concept 
is  understood  to  be  made  of  a number  of  parts  which  in  turn  are  made  of  parts  and  so 
on  forming  a hieararchy  of  parts.  The  originating  concept,  in  this  case,  represents  a 
composite  construct.  The  use  of  part-,  set-,  or  type-generalization  with  the  originating 
concept  identifies  a construct  as  being  a composite,  set,  or  classification  respecitively. 


4.2.1  Composites 

Composites  are  constructs  that  serve  to  identify  a whole  as  being  made  of  a number  of 
parts.  Composites  therefore  use  part-generalization  at  the  originating  level  of  the  con- 
struct. An  example  composite  for  a building  might  view  it  as  a simple  list  of  parts  (an 
approach  not  taken  by  the  AEC  Model). 

(part) 

[building  ] 

[ceiling] 

[floor] 
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In  the  above  example  any  or  all  of  the  parts  could  themselves  be  made  of  parts  and  the 
composite  construct  of  a building  would  include  the  ideas  representing  that  further 
breakdown. 

An  alternative  composite  views  a building  as  including  only  the  concepts  building-sys- 
tem and  building-element  at  the  originating  level.  Building-system  and  building-ele- 
ment are  in  turn  made  up  of  various  kinds  of  systems  and  elements.  This  is  the  ap- 
proach used  in  the  AEC  Model. 

(part) 

[building] 

[building-element] 

[building-system], 

(subtype) 

[building-element] 

[ceiling] 

[floor] 

[roof] 

[room] 

[wall], 

(subtype) 

[building-system] 

[engineering-system] 

[non-engineering-system], 


Since  in  this  construct  a wall  is  a subtype  of  a building  element,  and  a building  element 
is  a part  of  a building,  it  follows  that  a wall  is  also  a part  of  a building.  Similarly  parts 
or  subtypes  of  a wall  can  also  be  seen  to  be  included  in  a composite  view  of  a building. 
This  example  illustrates  the  use  of  a concept  classification  (involving  type-generaliza- 
tion) being  incorporated  within  a composite  construct. 


4.2.2  Sets 

Sets  are  constructs  that  use  set-generalization  at  the  originating  level.  Sets  identify  col- 
lections of  concepts  that  do  not  necessarily  have  anything  in  common  other  than  that 
they  are  members  of  the  same  set. 
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4.2.3  Classifications 


Classifications  are  constructs  that  provide  the  ability  to  view  information  in  a hierar- 
chical arrangement  of  categories,  each  subsequent  level  adding  more  detailed  infor- 
mation. Classifications  use  type-generalization  at  the  originating  and  all  subsequent 
levels  of  the  construct.  They  are  often  included  as  a portion  of  composite  constructs 
(see  Section  4.2.1).  Classifications  are  particularly  useful  in  organizing  building  infor- 
mation where  taxonomies  of  building  elements  and  systems  are  central  issues  in 
developing  a global  model. 

An  important  aspect  of  the  AEC  Model  is  its  systems  approach  to  organizing  informa- 
tion about  a building.  Figure  1 presents  a hierarchy  that  represents  the  classification 
of  concepts  under  the  heading  of  building-system.  The  representation  is  of  the  struc- 
ture only  and  does  not  explicitly  identify  the  relationships  between  concepts  involving 
type-generalization.  However,  since  the  structure  is  identified  as  a classification,  the 
subtype  relation  is  implied  throughout. 

An  alternative  classification  is  presented  in  Figure  2.  This  classification  takes  the  view 
that  building  systems  can  be  subdivided  into  enclosure,  interior,  mechanical,  and  struc- 
tural systems.  All  other  building  systems  fall  under  these  four  classes.  This  alternative 
structure  reflects  an  organization  suggested  in  "The  Building  Systems  Integration 
Handbook"  published  by  the  American  Institute  of  Architects  [12].  Deciding  between 
such  details  within  a generalization  hierarchy  is  a major  aspect  of  developing  a concep- 
tual schema. 

Table  6.  presents  the  ideas  of  the  building-system  classification  shown  in  Figure  2. 
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building-system 


engineering-system 

communication-system 

conveyance-system 

electrical-system 

lighting-system 

mechanical-system 

acoustical-system 

fire-protection-system 

hvac-system 

plumbing-system 


structural-system 

non-engineering-system 

circulation-system 

enclosure-system 

internal-subdivision-system 

external-envelope-system 

aperture-system 


interior-system 

spatial-system 


Figure  1.  A Building-System  Classification. 
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building-system 


enclosure-system 

internal-subdivision-system 

external-envelope-system 

aperture-system 

interior-system 

circulation-system 

spatial-system 

mechanical-system 

acoustical-system 

communication-system 

conveyance-system 

electrical-system 

fire-protection-system 

hvac-system 

lighting-system 

plumbing-system 

structural-system 


Figure  2.  An  Alternative  Building-System  Classification. 
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Table  6. 

Ideas  in  a Building-System  Classification. 

ParRel 

PrimObj 

AuxObj 

subtype 

building-system 

enclosure-system 

interior-system 

mechanical-system 

structural-system 

subtype 

mechanical-system 

acoustical-system 

communication-system 

conveyance-system 

electrical-system 

fire-protection-system 

hvac-system 

lighting-system 

plumbing-system 

subtype 

enclosure-system 

internal-subdivision 

external-envelope 

opening 

subtype 

interior-system 

circulation-system 

spatial-system 

4.3  Prototypes 

When  a concept  is  developed  and  that  concept  is  also  contained  within  a type- 
generalization  hierarchy,  the  developed  concept  (i.e.,  its  ideas)  can  be  inherited  within 
the  context  of  that  hierarchy.  This  kind  of  construct  is  referred  to  here  as  a prototype 
concept.  It  is  something  of  a cross  between  a developed  concept  and  a construct.  It 
includes  both  the  aggregation  of  ideas  in  which  the  initial  concept  is  involved  and  pos- 
sibly other  selected  ideas  that  extend  beyond  that  aggregation. 
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Table  7.  Ideas  in  a Prototype  Engineering-System. 

Relation 

Concept  1 

Concept  2 

accesses 

engineering-system 

utility-system 

divides 

zone 

engineering-system 

part 

engineering-system 

system-component 

part 

engineering-system 

directed-network 

part 

directed-network 

device-part 

represents 

device-part-geometry 

device-part 

supports 

structural-system 

system-component 

triggers 

control 

instrument 

subtype 

system-component 

control 

device-part 

instrument 

insulation 

Within  its  building-system  classification,  the  AEC  Model  has  developed  a prototype 
engineering-system  (Figure  7).  This  prototype  serves  as  a template  for  developing  the 
concepts  of  mechanical  and  structural  systems  since  it  specifies  ideas  that  are  believed 
to  hold  for  all  types  of  engineering  systems. 

In  considering  what  constitutes  an  hvac-system,  the  prototype  engineering-system  can 
be  inherited  if  the  hvac-system  is  related  to  a mechanical-system  which  in  turn  is  re- 
lated to  an  engineering-system  by  type-generalization.  Therefore,  the  development  of 
the  hvac-system  concept  begins  with  inherited  ideas  which  can  be  derived  from  the 
prototype  engineering-system  followed  by  ideas  that  uniquely  specify  the  hvac-system 
concept. 
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Table  8. 

Inherited  Ideas  of  an  HVAC-System  Concept. 

Relation 

Concept  1 

Concept  2 

accesses 

hvac-system 

utility-system 

divides 

zone 

hvac-system 

part 

hvac-system 

system-component 

part 

hvac-system 

directed-network 

part 

directed-network 

device -pan 

represents 

device-part-geometry 

device-part 

supports 

structural-system 

system-component 

triggers 

control 

instrument 

subtype 

system-component 

control 

device 

instrument 

insulation 

In  fact,  it  is  this  addition  of  lower  level  specific  ideas  to  higher  level  general  ideas  that 
justifies  the  use  of  type-generalization.  If  unique  information  is  not  added  by  lower 
level  classes,  the  division  into  subtypes  is  probably  not  appropriate. 

Table  8 presents  the  inherited  ideas  that  serve  to  develop  the  concept  of  an  hvac-sys- 
tem.  Table  9 expands  upon  the  concept  by  adding  ideas  that  are  unique  to  an  hvac-sys- 
tem.  Such  inheritance,  from  a prototype  to  concepts  that  represent  subtypes  of  the 
prototype,  is  a capability  that  needs  to  be  considered  when  developing  generalization 
hierarchies. 
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Table  9.  Non-Inherited  Ideas  of  an  HVAC-System  Concept. 

1 

Relation 

Concept  1 

Concept  2 

connects 

air-distribution-network 

air-distribution-device 

conntects 

water-distribution-network 

water-distribution-device 

subtype 

control 

temperature-control 

air-flow-control 

subtype 

device-part 

air-terminal 

conditioner-device 

air-distribution-device 

water-distribution-device 

water-terminal 

subtype 

air-terminal 

air-distribution-ceiling 

diffuser 

door 

grille 

light-fixture 

louver 

register 

roof-ventilator 

screen 

skylight 

vent 

window 

subtype 

conditioner-device 

cooling-conditioner 

heat-conditioner 

humindity-conditioner 

(continued) 
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Table  9.  (continued) 

Relation 

Concept  1 

Concept  2 

subtype 

water-terminal 

convector 

radiant-panel 

radiator 

unit-heater 
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5.  Summary  and  Conclusions: 


5.1  The  Conceptual  Schema  Development  Process 


The  development  of  a conceptual  schema  such  as  the  AEC  Model  has  at  least  four  es- 
sential aspects.  They  include: 


Topic  Process 


Concepts 

Relationships 

Ideas 

Constructs 


identification  and  development 
selection  of  Relation  &Roles 
assignment  of  Roles  to  Concepts 
identification  and  development 


The  process  of  schema  development  begins  with  the  identification  of  concepts  ap- 
propriate to  a given  domain.  In  the  case  of  the  building  industry,  this  is  itself  a for- 
midable task  and  is  therefore  expected  to  be  a continuing  effort. 

In  contrast  to  the  large  number  of  concepts  that 'can  be  expected  in  a global  conceptual 
model,  the  number  of  relations  used  in  describing  relationships  between  concepts  is 
much  smaller.  Further,  many  relations  that  are  appropriate  for  the  building  industry 
are  also  useful  in  other  domains.  Therefore,  identifying  relations  should  be  a matter 
of  selection  from  among  previously  identified  relations.  This  aspect  of  schema  develop- 
ment lends  itself  to  cooperative  efforts  across  disciplines. 


A problem  that  is  encountered,  however,  is  that  there  is  little  or  no  standardization  in 
the  manner  in  which  relationships  are  specified.  Many  data  models  (in  the  sense  of 
tools  used  to  develop  schemas)  have  their  own  way  of  defining  relationships.  Whether 
the  relation  and  roles  remain  separate  or  are  combined  in  a single  representation  is  the 
most  obvious  difference.  However,  the  details  of  the  words  used  to  express  the  relation- 
ships and  the  precise  syntax  of  their  specification  continues  to  be  problematic.  This 
report  has  described  an  initial  step  toward  resolving  this  important  issue. 

The  lack  of  consensus  is  also  serious  in  the  case  of  specifying  ideas.  Many  alternative 
representations  exist.  This  report  has  described  three  general  kinds  of  representation 
as  an  overview  of  the  sorts  of  differences  that  exist.  However,  it  is  important  to  note 
that  they  should  be  truly  alternative  representations.  The  underlying  semantics  must 
remain  the  same  though  expressed  in  different  ways.  In  those  cases  where  a particular 
representation  cannot  accommodate  necessary  semantics,  extensions  to  the  repre- 
sentation are  justified. 
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What  has  not  been  a part  of  the  specification  of  ideas  in  the  past  is  the  use  of  relation- 
ship types  to  assist  the  schema  developer.  Ideas  when  specified  in  a form  close  to 
natural  language  (e.g.,  a symmetric  representation)  should  use  certain  grammatical 
constructions.  The  definition  of  active,  dative,  locative,  and  partitive  relationship  types 
makes  this  point  explicit.  Roles  have  then  been  established  that  reflect  the  underlying 
semantics  attached  to  concepts  involved  in  these  types  of  relationships.  This  approach 
allows  for  explicit  statements  of  meaning  that  can  serve  as  a check  for  alternative  rep- 
resentations. In  this  context,  a representation  for  complex  ideas  has  been  developed 
for  the  special  case  of  ideas  involving  dative  relationships  to  address  the  underlying 
semantics  of  directed  transfer. 

Another  aspect  of  developing  a conceptual  model  emphasized  in  this  report  is  the  im- 
portance of  identifying  and  developing  constructs  within  the  conceptual  schema.  Com- 
posites, sets,  and  classifications  serve  to  establish  hierarchically  related  groups  of  ideas 
within  a conceptual  schema.  Identifying  constructs  involves  important  choices  that 
must  be  made  between  part-,  set-,  and  type-generalization.  When  using  type- 
generalization,  the  specification  of  prototypes  can  serve  as  templates  in  developing 
lower  level  concepts  within  a classification. 

These  aspects  of  the  development  of  conceptual  models  need  further  review  and  re- 
search. TTiey  can,  however,  be  applied  to  ongoing  schema  development  as  an  aid  to  the 
developer  in  considering  the  many  choices  that  are  to  be  made  during  that  process. 


5.2  Natural  Expression  of  Ideas 

The  development  of  a conceptual  schema  using  representations  that  are  similar  to 
natural  language  expressions  benefits  both  the  developer  and  most  other  individuals 
that  are  to  make  use  of  the  schema.  Internal  computer  representations  vary  greatly 
from  one  implementation  to  another.  Clear  conceptual  representations  offer  a means 
by  which  systems  can  be  developed  that  are  capable  of  communication  both  within  and 
between  disciplines. 

This  report  has  presented  a view  of  how  ideas  and  other  conceptual  structures  can  be 
specified  unambiguously.  Adoption  of  such  an  approach  (see  Table  10  as  an  example) 
presents  the  possibility  for  more  direct  comparison  and  integration’ of  conceptual 
schemas  than  is  currently  the  case.  Particularly  in  the  realm  of  relationships,  the  poten- 
tial for  developing  a consensus  semantic  vocabulary  from  which  schema  developers  and 
integrators  can  choose  seems  of  considerable  relevance  to  standardization  organiza- 
tions. 
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Table  10.  Natural  Expression  of  Ideas  by  Relationship  Type. 

Active 

Idea: 

ActObj-ActRel1 

air-quality_control 

Obv 

Actor  ActRelfs]2  ActObj 

hvac-system  controls  air-quality 

Inv 

ActObj  [is-]ActRel[ed-by]3  Actor 

air-quality  is-controlled-by  hvac-system 

Dative  (Complex  Idea) 

Idea: 

Source_[to]_Target_DatObj_[transfer4] 

gutter_to_downspout_water_transfer 

Obv. 

S ource- [to] -Target-DatObj- [transfer] 

gutter-to-downspout-water-transfer 

" DatRel[s]  DatObj 

" conducts  water 

" [has-origin]  Source 

" has-origin  gutter 

" [has-destination]  Target 

" has-destination  downspout 

Inv. 

Source-  [to] -T arget-D  atObj  - [transfer] 

gutter-to-downspout-water-transfer 

DatObj  [is-]DatRel[edrby]  " 

water  is-conducted-by 

Source  [is-origin-of]  " 

gutter  is-origin-of  " 

Target  [is-destination-of]  " 

downspout  is-destination-of  " 

Locative 

Idea: 

LocObj_[location] 

building_location 

Obv 

LocObj  [is-]ObvLocRel  Loc 

building  is-on  site 

Inv 

Loc  [is-]InvLocRel  LocObj 

site  is-under  building 

Partitive 

Idea: 

PrimObj_ParRel 

building_part 

Obv. 

PrimObj  [has-]ParRel  AuxObj 

building  has-part  building-element 

Inv 

AuxObj  [is-]ParRel[-of]  PrimObj 

building-element  is-part-of  building 

1 Beginning  capital  letters  indicate  variables. 

2 Letters,  words,  and  characters  in  brackets  are  used  literally. 

3 Normal  rules  of  English  grammar  apply. 

4 Complex  ideas  involving  dative  relationships  represent  directed  transfer. 
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